Repository navigation
test(spring): [Sample Tests 42] Run each Spring Boot matrix version as its own Gradle task - #6382
Draft
runningcode wants to merge 2 commits into
Draft
runningcode wants to merge 2 commits into
runningcode wants to merge 2 commits into
Conversation
This was referenced Oct 26, 2026
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
📲 Install BuildsAndroid
|
5 of 9 tasks
This was referenced Oct 27, 2026
The Spring Boot matrix workflows tested each version by rewriting the catalog with perl, so a version could only be tested locally by editing the catalog, and every job recompiled the SDK and the suites. The new io.sentry.spring-boot-matrix plugin registers a test task per suite and version, e.g. integrationTestWebfluxBoot3_2_12. It reuses the suite's compiled classes on a runtime classpath resolved for that version, which swaps every org.springframework.boot artifact, the BOM included, as the catalog edit did. The resolved classpaths match the catalog edit's exactly. So the SDK and the suites now compile once, against the catalog's version, and only the runtime varies, which is how users run our jars. Suite code may only use APIs of the oldest version of its line. allIntegrationTestsBoot<version> runs one version's suites in a module, and allIntegrationTestsBoot<major> every version's. Each workflow runs the latter from the root in one job per Boot line, with --continue so a failing version doesn't hide the others. The versions live only in SpringBootVersions in build-logic. Resolves JAVA-802 Co-Authored-By: Claude <noreply@anthropic.com>
runningcode
force-pushed
the
no/spring-boot-matrix-tasks
branch
from
October 27, 2026 14:33
033bff7 to
8d9fab1
Compare
runningcode
force-pushed
the
no/drop-boot-2.4-2.6
branch
from
October 27, 2026 14:33
bed55a4 to
1b46292
Compare
One job per Boot line doubled the matrix wall time, e.g. 12.5 minutes instead of about 6 for Boot 3. A single runner ran every version's suites, and the bare task name made Gradle configure every project to find it. The versions move to gradle/spring-boot-versions.json. build-logic reads it, and each workflow turns its line into one job per version, which runs that version's aggregate in both modules by project path. The version list stays in one place, and the check names match main's again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Stack (Sample Tests)
main)📜 Description
Replaces the perl edit of
gradle/libs.versions.tomlin the Spring Boot matrix workflows with a Gradle task per suite and Spring Boot version.io.sentry.spring-boot-matrixplugin in build-logic. A module lists its suites in aspringBootMatrixblock, and the plugin registers<suite>Boot<version>for each version of its Spring Boot line ingradle/spring-boot-versions.json, e.g.integrationTestWebfluxBoot3_2_12.implementationandruntimeOnlyand swaps everyorg.springframework.bootartifact, the BOM included, to the version. That's what the catalog edit did.runAgentFixture, in both init modes.allIntegrationTestsBoot3_2_12runs one version's suites in a module, andallIntegrationTestsBoot3runs every version's.gradle/spring-boot-versions.json. Each job runs its version's aggregate in the Boot module and its WAR module by project path, e.g../gradlew :sentry-spring-jakarta:allIntegrationTestsBoot3_2_12 :sentry-spring-boot-jakarta:allIntegrationTestsBoot3_2_12. The check names are the same as onmain.gradle/spring-boot-versions.json, which build-logic and the workflows both read. The WAR suites insentry-spring{,-jakarta,-7}use their Boot module's list.e2e_tests.mdcnow describes the tasks.What changes: the SDK and the suites compile once, against the catalog's version, and only the runtime classpath varies. That's how users run our published jars, and it can catch binary incompatibilities that recompiling hid. Suite code may only use APIs that exist in the oldest version of its line. The next PR brings back a check that the SDK's main code compiles against that version.
Why still one job per version: this PR first ran each line in a single job, which doubled the wall time (Boot 3 took 12.5 minutes instead of about 6). One runner ran every version's suites, and the bare task name made Gradle configure every project.
💡 Motivation and Context
Closes #6379 (JAVA-802). A version could only be tested locally by editing the catalog by hand, and every matrix job recompiled the SDK and the suites. Now it's
./gradlew :sentry-spring-boot-jakarta:allIntegrationTestsBoot3_2_12.💚 How did you test it?
integrationTestat 3.2.12;sentry-springand the Boot 2integrationTestOtelNoAgentat 2.7.0;sentry-spring-7and the Boot 4integrationTestOtlpat 4.0.0.📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
#6383 compiles the SDK against each line's oldest version.
#skip-changelog
🤖 Generated with Claude Code